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Het  project  ‘RTPI  prototype’  (Real-Time  Performance  Indicator)  betreft  een 
ontwikkelopdracht  voor  de  Koninklijke  Marine  ten  behoeve  van  de  mijnenjacht. 
Het  systeem  heeft  tot  doel  om  door  middel  van  simulatie  een  indicatie  te  geven  van 
de  karakteristieke  detectiebreedte  (A  waarde)  en  de  karakteristieke  detectiekans  (B 
waarde).  De  simulatie  maakt  gebruik  van  invoer  gegevens  die  zowel  met  de  hand 
ingegeven  kunnen  worden  als  ter  plekke  gemeten  kunnen  worden  met  hiertoe  door 
het  MEOB  ontworpen  en  gebouwde  apparatuur.  Voor  de  simulatie  wordt  gebruik 
gemaakt  van  een  aangepaste  versie  van  HUNTOP.  Hardwarematig  is  het  FEL-deel 
van  RTPI  gebaseerd  op  OPPAS  waaruit  het  ook  een  deel  van  de  meetgegevens 
betrekt. 

Dit  rapport  beschrijft  de  ontwikkeling  van  het  prototype  en  de  daarmee 
samenhangende  ontwerp  beslissingen.  De  specificaties,  het  ontwerp,  de 
implementatie  en  de  tests  zijn  gedocumenteerd  in  (deliverable)  werkdocumenten. 

In  paragraaf  6.2  wordt  ingegaan  op  de  integratie  van  een  performance  indicator  aan 
boord.  De  nieuwe  scheepsconfiguratie  wijkt  echter  dermate  sterk  af  van  de  huidige 
dat  de  RTPI  niet  zonder  meer  geschikt  is  voor  de  nieuwe  scheepsconfiguratie.  Dit 
rapport  bevat  dan  ook  niet  de  specificatie  voor  de  serieproduktie. 

Het  RTPI  project  is  gestart  in  augustus  1994,  in  oktober  van  dat  jaar  zijn  de 
specificaties  opgeleverd  aan  de  KM  ter  goedkeuring,  waama  het  ontwerp  en  de 
implementatie  gestart  zijn.  In  maart  1996  heeft  de  Factory  Acceptance  Test 
plaatsgevonden  en  in  mei  1996  is  het  systeem  aan  de  KM  opgeleverd.  Eveneens  in 
mei  is  het  project  OPEVAL  (OPErationele  EVALuatie)  gestart  om  de 
bruikbaarheid  van  het  concept  in  de  praktijk  te  beproeven  en  enkele  specifieke 
aspecten  van  de  data  acquisitie  nader  te  beschouwen. 

Naar  aanleiding  van  de  ervaringen  van  de  eerste  maanden  zijn  in  juli  1996  enkele 
verbeteringen  in  het  systeem  aangebracht.  Deze  verbeteringen  betreffen  wensen 
van  de  KM  ten  aanzien  van  het  bedieningsgemak  en  enkele  diagnostische  routines. 
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Management  summary 


The  project  ‘RTPI  prototype’  (Real-Time  Performance  Indicator)  is  an  assignment 
by  the  Royal  Netherlands  Navy  to  develop  such  a  system  for  mine  hunting 
operations.  The  purpose  of  the  system  is  to  give  indications  of  characteristic 
detection  width  (A  value)  and  characteristic  detection  probability  (B  value)  by 
means  of  simulation.  The  simulation  uses  input  values  which  can  be  entered 
manually  or  can  be  measured  on  location  with  equipment  developed  by  MEOB. 
The  simulation  kernel  is  a  specially  adapted  version  of  HUNTOP  (HUNTing 
operations).  The  RTPI  hardware  is  based  on  OPPAS  (Operational  PAP  Simulator) 
from  which  RTPI  also  obtains  some  of  its  measurements. 

This  document  describes  the  development  of  the  prototype  and  the  design 
decisions  involved  in  this  process.  The  specifications,  design,  implementation  and 
tests  are  documented  in  separately  delivered  documents.  Paragraph  6.2  addresses 
the  integration  of  a  performance  indicator  aboard  a  mine  hunter.  The  new  mine 
hunter  configuration  however  differs  considerably  from  the  current  configuration. 
As  such  the  current  RTPI  does  not  suit  the  new  configuration  and  therefore  this 
report  does  not  contain  a  specification  for  the  production  of  RTPIs. 

The  RTPI  project  was  started  in  August  1995,  in  October  of  that  year  the 
specifications  were  delivered  to  the  Navy  for  approval.  After  approval,  RTPI  was 
designed  and  implemented  resulting  in  a  Factory  Acceptance  Test  in  March  1996. 
The  system  was  finally  delivered  to  the  Navy  in  May  1996.  In  the  same  month  the 
OPEVAL  (Operational  EVALuation)  was  started  to  assess  the  usefulness  of  the 
concept  in  an  operational  context  and  to  evaluate  some  specific  aspects  of  the  data 
acquisition. 

The  trials  conducted  during  the  first  months  of  operation  resulted  in  several 
enhancements  to  the  system.  The  enhancements  pertain  to  demands  by  the  Navy 
for  improved  ease  of  use  and  some  diagnostic  routines.  These  improvements  were 
implemented  in  July  1996. 
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1.  Abstract 


The  ‘RTPI  prototype’  system  is  a  precursor  to  the  RTPI  series  production.  Its 
intent  is  to  gain  experience  with  such  a  system  during  an  ‘operational  evaluation’ 
of  the  prototype  system.  RTPI  (Real-Time  Performance  Indicator),  in  the  CUP 
(Capability  UPgrade)  called  SPI  (Sonar  Performance  Indicator),  is  a  system  which 
assesses  the  quality  of  mine  detection  using  a  sonar.  The  system  is  designed  for  the 
‘Alkmaar’  class  mine  hunters  equipped  with  dedicated  instrumentation  for 
measurement  of  the  sound  velocity  profile,  the  absorption  and  reverberation  in  the 
vicinity  of  the  hunter  at  the  time  of  the  operation  (hence  real-time).  The  quality  of 
mine  detection  is  expressed  as  a  detection  probability  curve  which  indicated  the 
detection  probability  as  a  function  of  the  athwart  distance  and  as  A  and  B  values 
which  indicate  the  characteristic  detection  width  and  the  characteristic  detection 
probability. 

The  system  is  enclosed  in  the  OPPAS  rack  and  uses  many  of  the  OPPAS  system 
interfaces.  RTPI  incorporates  the  HUNTOP  simulator  which  simulates  a  mine¬ 
hunting  operation  (detection  phase)  using  real-world  environment  data  and 
computes  the  desired  probabilities. 

This  report  describes  the  development  of  the  TNO-FEL  part  of  the  system.  It 
presents  an  overview  of  the  system  and  elaborates  on  design  decisions  which  had 
to  be  made  in  the  course  of  development.  This  report  does  not  contain 
documentation  about  the  system,  the  system  is  documented  in  the  documents  listed 
in  appendix  A. 

Recommendations  on  future  research,  tools  and  enhancements  are  made  in 
chapter  6. 
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2.  Introduction 

2.1  RTPI  system 

The  “Real-Time  Performance  Indicator”  (RTPI)  is  a  system  which  estimates  and 
predicts  the  quality  of  a  mine  hunting  operation  by  means  of  simulation  using 
(real-time)  measured  environmental  data.  These  measurements  include  water 
parameters  at  various  depths  and  reverberation  conditions.  The  quality  of  the 
hunting  operation  (detection  phase)  is  expressed  in  both  a  P(y)  curve  (athwart 
detection  probability)  and  A/B  values  (characteristic  detection  width  and 
characteristic  detection  probability). 


2.2  RTPI  report 

This  document  is  the  last  in  a  series  of  RTPI  documents  which  together  make  up 
the  total  system  documentation  of  the  project  “RTPI  prototype”.  Chapter  5  and 
Apendix  A  give  an  overview  of  all  (TNO-FEL)  documents  produced  in  the  course 
of  the  project.  The  documentation  is  not  concise  in  the  sense  that  some  sub¬ 
systems,  though  essential  to  RTPI,  are  not  documented  by  TNO-FEL  because  they 
are  not  TNO-FEL  systems.  Also  source  code  is  not  provided  because  the 
intellectual  property  remains  at  TNO. 


2.3  RTPI  project 

At  the  date  of  publishing  of  this  report,  the  RTPI  system  is  in  the  state  of 
“operational  evaluation”  which  is  not  part  of  this  project.  The  RTPI  project  is  in 
the  state  of  ‘after  sales’  and  only  corections  to  bugs  will  be  applied  to  the  system. 
No  more  enhancements  to  the  current  version  (1.4)  are  currently  envisioned. 
Consequently  this  report  describes  the  current  (stable)  version  of  the  RTPI  system. 


3. 


System  Architecture 


The  system  architecture  is  defined  by  the  RTPI  specification  called  “Real-Time 
Performance  Indicator”  voor  de  Mijnenjacht,  een  Systeemspecificatie’  by 
Diepstraten  and  Vemooy  [FEL-92-A418].  After  the  contract  was  awarded  the 
system  was  further  specified  in  the  DMKM  approved  documents  23273.400/BB01 
Vl.O,  23273. 400/BB02  Vl.O  and  23273.400/BB03  Vl.O.  The  interfaces  between 
RTPI  sub-systems  were  defined  in  the  DMKM  approved  documents 
23273.401/BC01  Vl.O,  23273. 402/BC01  Vl.O  and  23273.403/BC01  Vl.O.  In  the 
implementation  phase  of  the  project  minor  changes  to  the  specification  and 
interface  definition  became  necessary.  Therefore  the  following  documents  were 
updated: 

•  23273. 400/BB02  VI.  1  User  Interface  Document; 

•  23273.402/BC0I  V2.1  RTPI-MEOB  IDD; 

•  23273.403/BC01  V2.1  RTPI-HYDRAUT  IDD. 

The  user  interface  document  specifies  the  menu  structure  and  the  screen  lay-outs. 
The  menu  structure  is  adhered  to  but  the  actual  screen  lay-outs  sometimes  differ 
for  reasons  of  space  efficiency  and  greater  ease-of-use. 


3.1  Hardware  architecture 

3.1.1  System  overview 

The  hardware  architecture  is  shown  in  Figure  1.  It  should  be  noted  that  the  RTPI 
processing  unit  with  the  disk  drives  is  enclosed  in  the  OPPAS  rack  and  that 
OPPAS  and  the  MEOB  interface  are  mounted  in  the  HYDRAUT  cabinet.  The 
probe  and  winch  are  mounted  on  deck  and  the  reverberation  unit  is  mounted  in  the 
sonar  array. 
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Figure  1:  Hardware  configuration. 

The  interfaces  to  the  display  unit,  sonar  and  Doppler-log  were  already  present  in 
OPPAS.  The  interfaces  to  Hydraut  and  the  MEOB  interface  (measurement  unit)  as 
well  as  the  communication  over  the  VME-bus  were  designed  specifically  for  this 
project  and  are  documented  in  the  specification  documents  mentioned  and  in  the 
design  documents  23273.610/CB01  and  23273. 620/BN01.  The  interfaces  between 
the  measurement  unit  and  the  probe,  winch  and  reverberation  unit  are  beyond  the 
scope  of  the  TNO-FEL  documentation. 

In  order  for  the  system  to  function  properly,  all  systems  shown  in  Figure  1  must  be 
powered-on.  When  the  measurement  unit  is  off,  no  communication  with  the 
sensors  is  possible  and  RTPI  will  sound  the  beeper  repeatedly  until  the  connection 
is  established.  When  the  Hydraut  is  off  or  when  the  connection  is  broken,  RTPI 
measurements  cannot  be  stamped  with  the  correct  time  and  location  information. 
Also  real-time  simulations  are  not  possible  because  of  the  lack  of  speed  and 
direction  information.  When  the  log  is  off,  log  information  will  not  be  logged. 
When  the  sonar  display  units  are  off,  the  recorder  circuit  boards  will  not  be 
powered  and  RTPI  will  be  slowed  down  due  to  communication  failures  with  these 
boards. 

3.1.2  Changes  to  existing  hardware 

The  RTPI  processing  board  and  interconnect  board  fit  in  two  free  slots  of  the 
OPPAS  VME  backplane.  The  disk  drives  are  mounted  in  the  original  position  of 
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the  battery  compartment.  The  battery  compartment  has  been  moved  to  a  position 
just  below  its  original  location.  During  normal  OPPAS  operation,  the  connection 
between  the  PAP  console  and  the  PAP  is  broken.  When  RTPI  is  operational  this 
connection  is  re-established  by  software.  However,  when  powering  up  or  when 
executing  OPPAS,  the  PAP  is  still  disconnected.  Without  the  connection  the  PAP 
releases  its  guide-rope  and  MDW  (Mine  Disposal  Weapon).  This  situation  cannot 
be  avoided  by  the  system  but  must  be  avoided  by  procedures. 


3.2  Emulators 

In  order  to  facilitate  concurrent  engineering  at  MEOB,  Van  Rietschoten&Houwens 
and  TNO-FEL,  emulators  were  designed  and  built.  These  emulators  were  used  as 
executable  specifications  during  development  and  as  data  entry  devices  during 
testing.  The  emulators  were  developed  early  in  the  project  and  tested  extensively. 
Parts  of  the  code  were  later  used  in  the  actual  RTPI  code. 


3.3  Software  architecture 

RTPI  consists  of  several  computers,  each  running  their  own  software.  RTPI 
involves  at  least  the  following  computers: 

•  OPPAS  PME  board,  procured  and  programmed  by  TNO,  runs  start-up  code  and 
data  acquisition  code  (Hydraut,  sonar  etc.). 

•  XVME  board,  procured  and  programmed  by  TNO,  runs  the  core  of  the  RTPI 
software. 

Measuring  unit,  developed  by  MEOB,  runs  data  acquisition  and  winch  control. 

•  Probe  computer,  developed  by  MEOB,  runs  data  acquisition  software. 

•  Emulators,  programmed  by  MEOB  and  EEL,  used  during  development. 

Software  specifically  designed  or  modified  for  RTPI  is  also  present  in  the  winch, 
sensors  and  Hydraut. 

3.3.1  Overview 

In  this  chapter,  we  will  concentrate  on  the  software  running  on  the  RTPI 
processing  board  (XVME-674).  This  software  was  designed  according  to  the 
object-oriented  methodology  and  is  entirely  written  in  C-i-i-.  There  is  a  source 
module  for  each  object  class.  We  distinguish  two  types  of  objects;  those  which  are 
created  and  destroyed  in  the  course  of  processing  (bottom  objects,  co-ordinates, 
etc.)  and  those  that  are  created  at  start-up  and  destroyed  at  exit  (user_interface, 
simulator,  database  etc.).  The  latter  type  is  often  associated  with  a  configuration 
file  which  it  reads  at  creation.  The  objects  can  also  be  categorised  as  belonging  to 
three  different  processes:  System  control,  Sensor  control  and  Performance 
calculation.  System  control  encompasses  the  user_interface,  input/output  (I/O) 
objects  and  the  database.  Sensor  control  is  taken  care  of  by  the  measuring_unit 


TNO  report 


10 


FEL-97-A219 


object  and  Performance  calculation  is  done  by  the  simulator  object  with  its 
associated  model  objects. 

3.3.2  The  main  process 

The  main  process  first  creates  all  permanent  objects  needed  for  RTPI  operation 
and  establishes  connections  between  those  objects.  Once  this  is  completed,  the 
user  interface  is  started  and  RTPI  is  operational.  When  the  user  selects  ‘end  RTPT, 
all  objects  are  destroyed  and  the  program  terminates.  A  batch  file  is  responsible  for 
the  restart  of  RTPI  and  for  possibly  other  house-keeping  tasks  (maintaining  system 
integrity,  deletion  of  temporary  files,  user  hooks  etc.). 

3.3.3  System  control 

The  RTPI  System  control  portion  is  documented  in  reports  23273. 64 1/BHOl  and 
23273.642/BHOl.  The  first  document  describes  the  user  interface  whereas  the 
latter  describes  the  database.  The  I/O  objects  (keyboard,  screen,  OPPAS  and 
printer)  are  not  covered  in  these  documents.  The  functionality  of  the  keyboard, 
screen  and  OPPAS  objects  is  described  in  the  OPPAS  software  document 
23273.620/BN01  because  communication  with  these  devices  takes  place  through 
OPPAS.  The  printer  object  provides  methods  to  initialise  the  printer  and  print  a 
character  on  the  printer. 

The  last  object  that  must  be  mentioned  in  this  chapter  is  the  ‘RTPI_values’  object 
which  is  responsible  for  the  administration  of  data  from  the  various  sources  (e.g. 
measured  data  or  user  defined  data).  In  fact  it  is  a  repository  for  all  kinds  of  data 
with  ‘get’  and  ‘set’  operators  for  each  data  item. 

3.3.4  Sensor  control 

Sensor  control  is  implemented  through  the  Measuring_unit  object  and  is 
documented  in  report  23273.631/BHOl. 

3.3.5  Performance  calculation 

The  performance  is  computed  by  the  ‘Simulator’  object.  The  simulator  object  is 
connected  to  many  model  objects  which  model  parts  of  the  real  world  like  ‘ship’, 
‘water’,  ‘mine’  etc.  These  objects  are  modelled  in  document  23273.650/BB01. 
These  objects  together  are  in  effect  the  HUNTOP  (HUNTing  OPeration) 
simulator.  Several  enhancements  were  made  to  HUNTOP  in  order  to  make  it  faster 
and  in  order  to  allow  the  use  of  real-time  measured  data. 
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4.  Implementation 

4.1  User  interface 

As  long  as  RTPI  is  active,  the  user  interface  is  polling  for  events  to  happen  and 
subsequently  dispatch  to  a  function  handling  the  event.  There  are  basically  three 
types  of  events.  Keyboard  events,  timer  events  and  exception  events.  Keyboard 
events  correspond  to  a  key-press  and  indicate  that  the  user  wants  RTPI  to  perform 
some  action.  Timer  events  indicate  that  it  is  time  to  perform  some  action,  usually 
to  gather  data  or  write  a  log-record.  Exceptions  are  messages  from  other  sub¬ 
systems  which  indicate  that  something  has  happened.  This  may  vary  from  perfectly 
normal  events  like  ‘bottom  hit’  to  fatal  events  like  ‘no  communication’  with  the 
measurement  unit.  Exceptions  are  always  reported  on  the  screen.  The  possible 
exceptions,  menu  staicture  and  screen  lay-outs  are  described  in  documents 
23273.400/BB02  (User  Interface  Document)  and  23273. 700/D  AO  1  (User’s 
manual). 


4.2  System  interfaces 

The  RTPI  processing  unit  has  interfaces  (directly  or  indirectly)  to  the  following 
systems; 

•  Detection  sonar  controls 

•  Doppler  log 

•  Winch 

•  Probe 

•  Detection  sonar  reverberation  signal 

•  Hydraut 

•  Display/keyboard  unit. 

4.2.1  Detection  sonar 

The  data  from  the  sonar  is  used  to  compute  the  sonar  footprint.  The  settings  of 
power  and  pulse  width  are  used  to  compute  the  contrast.  The  values  used  to  be 
updated  every  5  seconds  but  due  to  instability  of  the  signal  for  the  depression 
angle,  the  frequency  was  increased  to  once  per  second.  The  depression  data  is  then 
filtered  by  an  alpha  filter  with  (X=0.25.  This  means  that  fluctuations  are  damped 
with  a  factor  of  0.25  but  that  it  takes  longer  to  achieve  a  certain  accuracy.  With  the 
current  setting,  the  accuracy  is  18%  after  5  samples  (seconds).  I.e.  when  a  step  of  4 
degrees  is  applied  to  the  filter  (ignoring  fluctuations),  the  output  of  the  filter  will 
change  to  1  deg.  immediately  and  pass  through  1.75,  2.31,  2.73,  3.05  and  reach 
3.29  after  5  seconds.  This  value  is  0.71  degrees  (or  18%)  from  the  desired  value  of 
4  degrees.  The  following  table  shows  the  relationship  between  accuracy,  alpha  and 
number  of  samples. 
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Table  1:  Relation  between  damping,  accuracy  and  delay. 


alpha 

accuracy  (%) 

samples 

0.25 

18% 

6 

0.25 

10% 

8 

0.25 

1% 

24 

0.20 

10% 

10 

0.37 

10% 

5 

0.37 

1% 

10 

0.60 

1% 

5 

The  table  shows  that  there  is  a  trade-off  between  damping,  accuracy  and  delay.  A 
sonar  log  record  is  written  to  disk  whenever  a  button  setting  changed  or  the 
(filtered)  depression  angle  changed  by  more  than  a  pre-defined  tolerance  (0.5 
degrees). 

4.2.2  Doppler  log 

The  data  from  the  ship’s  log  is  only  used  for  logging  (for  later  analysis).  In  order 
to  conserve  disk  space,  the  logging  interval  is  set  rather  long  (10  minutes).  All  four 
values  from  the  log  are  recorded  even  when  only  the  speed  relative  to  the  water  is 
available.  A  new  record  is  written  only  when  any  of  the  speeds  has  changed  by 
more  than  a  pre-defined  tolerance  (1  m/s). 

4.2.3  Winch 

The  only  signals  retrieved  from  the  winch  are  its  status  bits.  The  ‘bottom  hit’  and 
‘to  block’  signals  are  in  fact  probe  signals  but  are  processed  as  though  they  were 
winch  signals.  The  winch  state  is  updated  on  the  screen  every  second.  Winch 
activity  is  not  logged.  When  the  probe  hits  the  bottom,  the  winch  will,  raise  the 
probe  2  meters  unless  the  probe  is  stuck  or  the  depth  sensor  is  defective  (RTPI  will 
fail  the  attempt  after  6  seconds).  From  release  1 . 1  on,  RTPI  will  not  attempt  to 
raise  the  probe  2  meters  after  a  bottom  hit  when  the  probe  is  not  submerged.  This 
feature  was  added  in  order  to  make  it  possible  to  put  the  probe  on  deck  in  an 
upright  position.  In  release  1.0  the  probe  was  raised  2  meters  immediately  after 
hitting  the  deck. 

4.2.4  Probe 

The  probe  update  time  is  pre-set  to  once  every  2  seconds.  At  a  winch  speed  of  0.5 
m/s,  this  corresponds  to  a  resolution  of  1  meter.  Every  interval,  the  following  data 
is  retrieved:  depth,  sound  velocity,  pH,  salinity,  temperature  and  a  sound  velocity 
computed  from  the  other  parameters. 

The  measured  values  are  checked  against  their  allowable  limits  and  when  they 
differ  from  the  previous  measurement  (by  at  least  their  resolution),  they  are  noted 
as  a  new  value  in  the  curve.  The  pH  value  is  treated  slightly  different  however 
because  this  is  not  measured  as  a  curve  but  as  an  averaged  value.  Because  the  pH 
sensor  is  quite  slow  (15  s  settling  time),  averaging  starts  after  15  seconds  (7.5m 
depth).  When  the  depth  is  less  than  7.5m,  a  default  pH  value  of  8.3  is  reported. 
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The  range  checking  on  the  measured  values  is  actually  ineffective  because  range 
checking  is  done  by  the  measurement  unit  (MEOB  part)  and  is  signalled  to  the 
processing  unit  in  a  separate  status  bit. 


Table  2:  Range  and  resolution  of  measured  values. 


minimum 

maximum 

resolution 

unit 

depth 

0 

200 

0.1 

m 

temperature 

-5 

105 

0.1 

°C 

salinity 

0 

1000 

0.1 

p.p.t. 

sound  velocity 

1400 

1600 

0.1 

m/s 

pH 

0 

14 

0.1 

4.2.5  Reverberation 

Reverberation  is  measured  with  one  of  the  hydrophones  in  the  sonar  array,  i.e.  the 
signal  is  NOT  taken  from  a  bundle.  This  means  that  the  sensitivity  is  nearly  omni¬ 
directional.  This  kind  of  measurement  is  all-right  for  noise  measurements  because 
noise  is  not  correlated  to  the  emitted  signal.  On  the  other  hand,  it  is  less  correct  for 
reverberation  measurement  because  it  does  not  take  into  account  the  directivity 
index  of  the  array.  Measuring  a  bundle  instead  of  a  hydrophone  is  much  more 
complicated  because  the  signal  is  compressed  by  the  AGO  (Automatic  Gain 
Control).  Measuring  the  value  of  the  AGC  as  well  is  difficult  because  the  AGC- 
signal  is  highly  non-linear  and  temperature  dependent.  REACT  simulations 
however  show  that  adding  an  offset  to  the  reverberation+noise  signal  in  dB 
(applying  a  constant  gain)  gives  a  good  approximation  of  the  signal  in  a  bundle. 

An  estimate  of  this  gain  is  17dB  but  must  be  determined  by  experiments  during  the 
operational  evaluation. 

The  measurement  of  the  reverberation  is  linear  in  dB  (i.e.  logarithmic)  with  a 
dynamic  range  of  almost  80dB  which  is  more  than  adequate  as  experiments  show  a 
dynamic  range  (in  the  useful  region)  of  50  to  60dB.  The  reverberation  signal  is 
sampled  every  10ms.  Depending  on  sonar  range  this  yields  between  55  and  120 
samples  per  sonar  ping.  Multiple  data-sets  from  pings  are  averaged  (from  ping  to 
ping)  using  an  alpha  filter.  The  current  implementation  uses  a  =  0.167. 


Table  3:  Relation  between  accuracy  and  settling  time. 


step  size  [dB] 

accuracy  [dB] 

samples 

time  [m:s] 

10 

0.1 

25 

2:05 

10 

1.0 

13 

1:05 

20 

0.1 

29 

2:25 

20 

1.0 

1 5 

1:20 

40 

0.1 

33 

2:45 

40 

1.0 

20 

1:40 

80 

0.1 

37 

3:05 

80 

1.0 

24 

2:00 
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Table  3  shows  the  relation  between  absolute  step-size,  absolute  accuracy  and  the 
settling  time  of  the  filter  for  the  given  alpha.  Not  every  ping  is  used  in  the 
computation.  In  order  to  reduce  computational  overhead,  only  one  ping  is  sampled 
every  5  seconds.  The  filtered  value  is  logged  to  disk  once  every  4  minutes  which  is 
well  beyond  the  settling  time.  The  filter  will  reduce  a  sine-shaped  modulation  with 
a  2  minutes  cycle  approximately  a  factor  of  2  in  amplitude. 

The  noise  value  is  estimated  from  the  measured  (and  filtered)  curve  by  averaging 
all  samples  beyond  0.5  seconds.  This,  under  the  assumption  that  reverberations 
have  faded  away  after  0.5s,  REACT  simulations  support  this  assumption. 
Operational  data  must  show  whether  this  time  needs  to  be  adjusted  and  whether 
different  gains  need  to  be  applied  to  reverberation  and  noise. 

In  RTPI  release  1.2  and  above,  the  distinction  between  reverberation  and  noise  for 
measured  reverberations  has  been  dropped.  The  contrast  is  determined  as  the 
difference  between  (computed)  echo  level  and  measured  background  level. 


Figure  2:  Sine,  step  and  impulse  response  of  alpha  filter. 


Figure  2  shows  the  filter  response  for  various  signals.  The  sine-period  is  80 
seconds,  corresponding  to  160m  at  4  knots. 


4.2.6  Hydraut 

A  dedicated  interface  to  Hydraut  (manufactured  by  Van  Rietschoten  &  Houwens) 
was  developed  in  order  to  acquire  data  about  time,  location,  course  and  speed. 
Time  and  location  are  used  only  for  stamping  of  other  log  data.  Course  and  speed 
are  used  in  real-time  simulation. 

OPPAS  requests  the  data  at  250ms  intervals  (longer  in  case  of  transmission  errors) 
and  the  RTPI  processing  unit  retrieves  the  data  from  OPPAS  at  1  second  intervals. 
A  transmission  error  recovery  algorithm  guarantees  that  the  reported  time  is 
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accurate  to  within  10s.  Otherwise  the  time  and  location  are  reported  as  ‘invalid’. 
The  Hydraut  course  and  speed  are  logged  to  file  (with  time  and  location  stamp) 
every  10  minutes,  provided  there  is  a  sufficient  change  from  the  previous  value. 

Table  4:  Hydraut  logging  criteria. 


Entity 

Tolerance 

Course 

2  degrees 

Speed 

0.5  knots 

4.2.7  Display/keyboard 

The  display/keyboard  unit  is  connected  to  OPPAS.  The  data  is  fed  through  OPPAS 
to/from  RTPI  over  the  VME  bus.  This  mechanism  is  described  in  document 
23273.620/BN01.  On  OPPAS  (the  OS9  side),  the  connection  to  the 
display/keyboard  unit  is  interrupt  driven,  using  a  standard  serial  device  driver.  The 
VME  connection  uses  polling.  A  VME  device  driver  would  have  incurred  less 
overhead  but  would  have  required  much  more  programming.  For  now,  OPPAS  can 
cope  with  the  extra  processing  and  therefore  an  interrupt  driven  device  driver  is 
not  really  necessary.  The  MSDOS  side  also  uses  polling  but  on  this  side  there  is  no 
alternative  because  the  PME  board  is  not  equipped  with  a  VME-bus  interrupter 
(the  XVME  board  is). 


4.3  Simulation  model 

The  simulation  model  is  a  specialised  version  of  HUNTOP  with  several 
extensions.  In  HUNTOP,  as  in  real  hunting  operations,  there  are  relatively  few 
mines  and  the  hunter  sails  a  complicated  track  in  order  to  hunt  all  mines.  In  order 
to  obtain  relevant  statistical  data,  lots  of  simulation  runs  are  necessary.  Therefore  a 
different  approach  was  exercised  in  RTPI.  Instead  of  few  randomly  scattered 
mines,  there  are  numerous  mines  on  a  regular  grid.  A  single  straight  track  is  sailed 
instead  of  a  user-definable  meander  track.  Doing  so  yields  lots  of  statistical  data 
within  a  single  run.  Of  course,  no  operator  can  cope  with  so  many  mines,  therefore 
the  operator  performance  is  computed  using  one  of  three  pre-defmed  mine 
densities,  independently  of  the  simulated  number  of  mines.  The  actual  number  of 
simulated  mines  depends  upon  the  sonar  search  window,  the  bottom  profile  and 
the  setting  of  the  ‘fast/accurate’  button. 

4.3.1  Module  Autopilot 

The  autopilot  travels  a  straight  track  such  that  the  entire  minefield  passes  once 
through  the  sonar  window. 
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4.3.2  Module  Bottom 

The  bottom  contains  the  hills,  see  the  User’s  manual  for  an  explanation  of  the  hill 
parameters. 

4.3.3  Module  Oparea 

The  operation  area  defines  the  minefield.  As  stated  earlier  in  this  chapter,  the 
minefield  generation  depends  largely  on  the  bottom  profile.  When  there  are  no 
hills  or  the  direction  of  travel  is  along  the  hills,  only  a  single  line  of  mines  across 
the  hunter’s  track  is  simulated  (the  length  of  the  field  is  zero).  The  width  of  the 
field  depends  on  the  sonar  settings  only. 

Table  5:  Minefield  width  as  function  of  sonar  range  and  sector  angle. 


Width 

30 

60 

90 

400 

BK&SE] 

600 

900 

465.9 

1272.8 

The  length  of  the  field  depends  on  the  sonar  range  and  relative  hill  orientation. 
When  the  direction  of  travel  is  perpendicular  to  the  hills,  the  length  equals  the  top 
to  top  distance  of  the  hills.  At  any  other  angle  (except  along  the  hills),  the  vertical 
field  size  is  longer  than  the  top  to  top  distance  but  never  longer  than  the  sonar 
range.  The  mine  spacing  depends  on  the  hills  and  on  the  ‘fast/accurate’  button. 
Some  spacings  are  expressed  in  ‘L’  which  is  one  third  of  the  length  of  the  steepest 
hill  slope  (unless  that  slope  is  vertical). 


Table  6:  Mine  spacing  for  'accurate'  simulation. 


direction 

along  ((p=90°) 

almost  along 

any  angle  (ip) 

perpendicular 

(<P=0°) 

horizontal 

Min(L,  5) 

Min(L,  5) 

Min(L/sin(p,  5) 

5 

spacing  [m] 
vertical 
spacing  [m] 

single  row 

5  rows 

Min(L/cos(p,  5) 

Min(L,  5) 

Table  7: 

Mine  spacing  for 

'fast'  simulation. 

direction 

along  ((p=90°) 

almost  along 

any  angle  (cp) 

perpendicular 

(9-0°) 

horizontal 
spacing  [m] 

Min(L,  10) 

Min(L,  10) 

Min(L/sin(p,  10) 

10 

vertical 
spacing  [m] 

single  row 

5  rows 

Min(l_/cos<p,  10) 

Min(L,  10) 
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4.3.4  Module  Simulator 

The  simulator  performs  the  actual  simulation  runs  and  determines  the  P(y)  curve. 
From  the  P(y)  curve  the  simulator  computes  the  A  and  B  values.  This  module  also 
incorporates  the  algorithm  for  the  computation  of  the  optimal  depression  angle. 
These  algorithms  are  described  in  document  23273.660/BJ01. 

4.3.5  Module  Sonar 

Although  this  module  has  no  special  provisions  for  RTPI,  there  is  one  sonar  issue 
which  must  be  understood.  The  sonar  object  has  an  attribute  called  ‘look_angle’ 
which  is  the  horizontal  angle  of  the  sonar  beam  relative  to  the  ship.  In  the  general 
HUNTOP  model,  this  attribute  is  allowed  to  have  any  value.  In  RTPI  however  this 
value  is  fixed,  not  measured  and  not  user  definable.  For  P(y)  and  A/B  to  be 
meaningful,  this  value  must  be  set  to  zero.  In  actual  RTPI  operation,  the  true  look 
angle  (as  set  by  the  sonar  operator)  should  also  be  zero  (looking  in  the  forward 
direction)  because  the  reverberation  values  might  be  dependent  on  this  angle. 

4.3.6  Module  Sonar  Operator 

The  sonar  operator  module  (sonope)  contains  the  operator  curves  as  defined  by 
GESMA  (“Performance  des  operateur  en  detection  de  mines”  by  Roger 
Philippart).  Different  curves  are  provided  for  low,  medium  and  high  mine 


densities. 

Table  8: 

Object  densities. 

Listbox  entry 

Object  density  [km'^j 

Low 

<26 

Medium 

26-60 

High 

>  60 

4.3.7  Module  Water  Volume 

The  watervolume  module  is  the  most  complex  module  in  the  model.  It  performs 
the  ray-tracing  and  determines  the  visibility  of  objects.  Objects  might  be  hidden  by 
hills.  Furthermore  this  module  computes  the  reverberation  and  absorption  for  a 
given  object.  Bottom-,  volume-  and  surface  reverberation  are  computed 
independently.  RTPI  is  configured  to  use  the  ‘SeaRays’  model  for  reverberation 
but  a  proprietary  ‘HUNTOP’  model  is  available  for  bottom  reverberation. 

When  RTPI  is  started  with  the  appropriate  arguments,  it  is  possible  to  generate  a 
file  which  lists  both  the  calculated  and  measured  reverberation  levels  as  a  function 
of  the  ‘ray_time’  (the  time  for  the  sound  to  travel  to  the  current  object  and  back). 
This  feature  is  very  useful  in  tuning  the  system  during  the  operational  evaluation. 
Two  absorption  models  are  available;  ‘Schulkin’  and  ‘Garrison’.  RTPI  is 
configured  to  use  ‘Garrison’  which  accounts  for  the  Boric  Acid  contribution  (for 
which  the  pH  is  needed). 
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4.3.8  Other  modules 

Many  more  modules  are  contained  in  RTPI  which  were  not  mentioned  in  this 
chapter.  Some  define  very  generic  classes  like  ‘Boolean’,  ‘Coordinate’  and 
‘Curve’.  Others  classes  are  specific  to  HUNTOP  but  not  to  RTPI  and  are  omitted 
for  brevity.  Full  documentation  can  be  found  in  the  software  documentation 
(23273.650/BB01). 
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5.  Documentation 


The  quality  assurance  programme  applicable  to  this  project  (AQAP  1)  requires 
consistent  documentation  and  document  identification.  In  this  chapter  all 
documents  subject  to  configuration  management  are  listed. 


5.1  Introduction 

All  documents  generated  as  part  of  the  RTPI  project  are  identified  by  a  unique 
identification.  The  format  of  this  identification  is: 

23273. www/XXnn 

In  this  identification  ‘23273’  is  the  internal  TNO-FEL  project  number,  ‘www’  is  a 
3  digit  number  which  identifies  the  work  package  and  XX  defines  the  document 
type.  The  two  trailing  digits  ‘nn’  are  used  for  various  purposes  like  sequence 
number,  revision  number  or  volume  number.  The  work  package  numbers  are 
defined  in  the  project  plan  (23273.000/AA01). 


Table  9:  Document  types. 


Identification 

Document  type 

AA 

project  plan 

AB 

work  packages,  financial  plan 

AC 

Integration,  installation  and  test  plan 

AF 

quality  assurance  plan 

AV 

minutes  of  external  meetings 

AZ 

memoranda 

BB 

system  specification 

BC 

interface  specification 

BH 

system  design 

BJ 

software  design 

BN 

detailed  software  design 

BV 

minutes  of  internal  meetings 

CB 

hardware  integration 

CH 

test  plan 

CK 

test  description 

CO 

test  report 

DA 

user’s  manual 

DB 

system  description 

FA 

configuration  registration 

FM 

external  reviews 

TNO  report 


FEL-97-A219 


20 


5.2  Document  overview 

An  overview  of  all  documents  delivered  in  the  course  of  the  project  is  presented  in 
Appendix  A.  The  table  shows  the  documents  identification  number,  a  brief 
description  and  the  latest  version  number  when  a  version  number  was  assigned. 
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6.  Future  Research 

6.1  Validation  and  verification 

Certain  aspects  of  the  RTPI  prototype  need  validation  before  the  system  can  be 
used  in  an  operational  environment.  An  operational  evaluation  is  needed  to  proof 
the  concept  of  performance  prediction  by  means  of  simulation.  Furthermore  the 
acquisition  and  processing  of  measurement  data  need  to  be  verified.  This 
verification  includes  the  accuracy  and  reliability  (repeatability)  of  the 
measurements,  most  notably  the  sound  velocity  and  reverberation  measurements. 
Also  the  filtering  of  data  must  be  evaluated.  Currently  filtering  is  applied  to 
reverberation,  depression  angle  and  pH.  The  current  filter  characteristics  are  based 
on  estimates  of  physical  error  sources,  sampling  times  and  desired  response  times. 
Real-world  measurements  are  necessary  to  determine  whether  these  filters  should 
be  tuned  or  enhanced  (e.g.  higher  order  filters). 

The  frequency  of  data  logging  needs  to  be  evaluated.  Current  logging  intervals  are 
based  on  estimated  rate  of  change  and  available  disk  space  (reasonable  amount  of 
floppy  disks  and  crew  effort). 

The  ease  of  use  of  the  system  needs  to  be  evaluated  in  order  to  derive  system 
requirements  for  the  series  production.  Especially  the  number  of  screens,  the  depth 
of  the  menu-structure  and  the  amount  of  information  on  the  screens  must  be 
evaluated. 

Though  the  HUNTOP  simulation  core  has  been  validated  in  previous  trials,  certain 
aspects  specific  to  the  RTPI  implementation  may  need  further  attention: 

•  The  use  of  measured  reverberation;  consistency  and  differences  with  the  model 
must  be  checked  and  explained. 

•  Optimal  depression  angle  computation;  RTPI  maximises  the  W  value, 
evaluation  should  show  whether  ‘aggregate  contrast’  is  a  better  criterion. 

•  Fixed  pitch  (grid)  minefield;  in  rare  cases  the  number  of  mines  may  be  too 
limited  or  the  fixed  pitch  of  the  mines  may  cause  aliasing  problems.  It  should 
be  investigated  whether  this  occurs  in  practice. 


6.2  Integration  within  a  Command  and  Control  System 

The  current  version  of  RTPI  is  a  prototype,  it  is  intended  to  demonstrate  feasibility 
and  to  gain  experience  with  such  a  system.  RTPI  has  interfaces  which  may  not  be 
present  in  the  future.  Future  mine  hunters  may  lack  a  PAP  and  hence  OPPAS, 
though  a  similar  system  may  be  present.  Therefore  in  the  future,  it  is  advantageous 
to  interface  RTPI  to  a  Command  and  Control  (C2)  system.  In  this  way,  RTPI  is 
connected  to  one  system  only.  This  still  leaves  the  options  of  implementing  RTPI 
as  a  normal  application  on  the  C2  platform(s)  or  to  implement  RTPI  on  a  dedicated 
platform. 
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Table  10:  Advantages  of  platform  options. 


Application  on  C2  platform 

Dedicated  RTPI  platform 

reduced  hardware  costs 
flexible  system  design 
uniformity  in  operating  systems 
less  space  occupation 
uniformity  with  C2  environment 

no  performance  penalty  on  C2  system 
high  level  of  system  integrity 
freedom  of  operating  system 
lower  implementation  and  maintenance  costs 
uniformity  with  RTPI  prototype  environment 

The  actual  implementation  also  depends  on  the  boundary  between  RTPI  and  C2 
system.  When  the  C2  system  is  made  responsible  for  all  data  acquisition  (and 
winch  control)  and  logging,  RTPI  shrinks  to  the  simulation  model  and  the  user- 
interface  which  has  to  be  modified  anyway.  In  this  case,  implementation  as  just 
another  application  on  the  C2  system  makes  more  sense  than  a  separate  platform. 
On  the  other  hand,  when  RTPI  is  responsible  for  the  acquisition  of  real-time  data 
and  winch  control  (data  which  is  not  necessary  for  other  C2  applications),  a 
dedicated  RTPI  computer  which  interfaces  directly  to  the  measurement  unit  is 
quite  attractive.  Other  data  can  be  obtained  from  the  C2  system  by  any 
communications  protocol. 

Integration  with  a  C2  system  gives  access  to  new  sources  of  RTPI  input  data. 
Especially  minefield  data,  which  must  be  entered  manually  at  the  moment,  can  be 
obtained  from  an  electronic  map. 


6.3  Effects  of  different  sonar  equipment 

In  the  future,  different  sonars  than  the  DUBM2I  may  be  used.  In  general,  this  will 
mean  that  the  interface  to  the  sonar  will  change  and  that  the  sonar  model  needs  to 
be  rebuilt.  The  interface  encompasses  the  settings  of  various  buttons  and  controls. 
Possibly  (likely)  new  controls  need  to  be  added  to  the  interface  and  the  translation 
from  control  to  real-world  value  has  to  be  changed.  Also  the  way  in  which  the 
reverberation  signal  can  be  derived,  may  change. 

The  changes  to  the  sonar  model  may  be  extensive,  especially  when  a  PVDS 
(Propelled  Variable  Depth  Sonar)  will  be  used  instead  of  a  hull  mounted  sonar. 


6.4  Off-line  use  and  tools 

6.4.1  Log  files 

During  normal  operation  RTPI  acquires  and  logs  an  abundance  of  data.  This  data 
is  intended  for  off-line  analysis,  storage  for  later  use  or  construction  of  a  database 
(e.g.  by  the  Mine  Warfare  Data  Centre  (MWDC).  Currently  there  are  no  tools 
available  for  the  handling  of  the  logged  data.  The  amount  of  data  is  typically 
1.44M  per  day. 
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Though  the  file  format  is  plain  ASCII  and  can  be  imported  into  for  instance 
‘Excel™‘,  it  is  recommended  to  use  a  dedicated  tool  for  the  translation  because  the 
file  format  is  not  guaranteed  to  remain  the  same  in  future  versions. 

6.4.2  Resource  files 

RTPI  uses  resource  files  in  its  computations  as  a  user  selectable  source  of  pre¬ 
defined  data.  The  user  can  add  and  remove  resource  files  to/from  the  RTPI  system 
through  the  database  maintenance  screen.  Currently  there  is  no  tool  available  to 
create  these  resource  files.  The  resource  files  are  plain  ASCII  files  and  can  be 
edited  using  any  text  editor.  This  technique  is  strongly  discouraged  however 
because  errors  in  this  procedure  can  corrupt  the  file  which  can  easily  crash  the 
system.  Therefore  it  is  recommended  to  use  a  dedicated  resource  editor  which  not 
only  ensures  system  integrity  but  also  ensures  file  compatibility  across  different 
versions.  Moreover,  such  a  tool  could  allow  translation  from  measured  profiles 
into  resource  profiles. 

6.4.3  Performance  calculation 

The  main  purpose  of  RTPI  is  to  compute  the  performance  of  a  mine  hunting 
operation  (detection  phase).  These  computations  can  be  done  using  real-time  data 
or  using  stored  data.  The  latter  possibility  is  useful  for  planning  and  what-if 
analysis.  It  can  be  desirable  to  perform  these  computations  also  off-board,  e.g.  for 
validation  or  further  analysis.  At  this  time  however,  RTPI/HUNTOP  are  not 
deliverable  as  desktop  PC  programs.  Depending  on  the  desired  level  of  emulation, 
it  is  technically  possible  however  to  port  RTPI  to  a  desktop  PC. 
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